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FOREWORD 

This Chartreuse Book is a companion book to reference [1] and contains rationale and explanatory 
material for the Recommendations therein. In the process of creating Member Agency standards, it 
should be used to justify and illustrate these concepts. Coordination among the Member Agencies 
is required to ensure that individual implementations conform to the SFDU structuring and data 
definition interchange standards specified in the applicable CCSDS Panel 2 approved 
Recommendation . 

This document presents a description of possible Control Authority (CA) operations modeled on 
the CA Procedures Recommendation. CA operations are described in terms of the functions 
performed in the management and control of data descriptions (metadata). The document also 
illustrates a potential operational view of a CA through scenarios describing interaction between 
those organizations involved in collecting, controlling, and accessing registered metadata. The 
roles interacting with the CA are identified by their actions in requesting and in responding to 
requests for metadata, and with the information exchanged. 

The scenarios and examples presented in this document are illustrative only. They could be 
supported by either a manual or automated system. These scenarios identify requirements for an 
automated system; these are expressed by identifying the information to be exchanged and the 
services that may be provided by a CA. 

This Report serves a variety of readers. It is principally intended to aid in understanding the 
Control Authority Procedures Recommendation, CCSDS 630.00-R-l, now in Agency review as a 
Red Book. In addition, it will support two future Blue Books on Automated Registration and 
Dissemination Services. 

This Chartreuse Book also serves as an example CA when establishing a MACAO, and will be 
used as the basis for. a Control Authority Set Up Guide. Additionally, this Report can help users 
understand aspects of their interactions with a Control Authority. This information is expected to 
be the foundation for a future CA Services User's Guide. 
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1.0 DOCUMENT PURPOSE AND ORGANIZATION 

1.1 PURPOSE 

The purpose of this document is to illustrate a Control Authority's (CA) possible operation. The 
document is an interpretation and expansion of the concept found in the CA Procedures 
Recommendation. The CA is described in terms of the functions it performs for the management 
and control of data descriptions (metadata). Functions pertaining to the organization of Member 
Agency Control Authority Offices (MACAOs) (e.g., creating and disbanding) are not discussed. 
The document also provides an illustrative operational view of a CA through scenarios describing 
interaction between those roles involved in collecting, controlling, and accessing registered 
metadata. The roles interacting with the CA are identified by their actions in requesting and 
responding to requests for metadata, and by the type o/wkh information exchanged. 

The scenarios and examples presented in this document are illustrative only. They represent 
possible interactions supported by either a manual or automated system. These scenarios identify 
requirements for an automated system. These requirements are expressed by identifying the 
information to be exchanged and the services that may be provided by a CA for that exchange. 

1.2 ORGANIZATION 

Section 1 contains the purpose and organization of this document 

Section 2 presents descriptions of roles and the definitions of key terms. The roles identify define 

i 

the types of organizational entities that interact with the CA. The definitions identify d e fin e the 
types of information exchanged between the CA and these other organizations. 

Section 3 contains a discussion of Control Authority functions. These functions pertain both to the 
mandatory responsibilities the CA has per reference [1], as well as additional responsibilities 
deemed reasonable to operate a MACAO and th e function s i t- ean p e rform . 

Section 4 contains scenarios of CA interaction with other organizational entitie s, eae h -. The 
organizational entities are defined by a role in Section 2. 


ISSUE- 1 


PAGE 1-1 


1/15/91 


DRAFT 


CCSDS REPORT: SFDU-CONTROL AUTHORITY OPERATIONS 

Annexes A and B respectively contain a list of acronyms and a glossary of key terms used in this 
document. Annex C contains a description of the capabilities needed by an organization to conduct 
Control Authority operations. Annex D contains an example of the registration and dissemination 
process for a specific implementaiton of an automated control authority. Ann e x E defin es th e data 
e ntities st or e d and controll e d at a MACAO ; Annex E F contains blanks of the forms presented in 
Section 4.0 of this document. Annex F E defines the data entities stored and controlled at a 
MACAO. Annex G contains descriptive scenarios of MDO usage use from a user (data producer) 
perspective. 
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DEFINITIONS 


This section provides descriptions of the roles involved in the control, registration, and access of 
data descriptions, as well as definitions of key terms. Figure 2.0-1 depicts the roles and the 
primary information they exchanged between them. Both inter-MACAO administrativ e (r e quir e d 
and local option) and user interactions are portrayed. Section 2. 1 defines d e scrib es the re l ev an t 
roles and their relevant responsibilities, and Section 2.2 provides definitions of the key terms 
representing the key information in the CA environment use d-in- thi s- docum e nt 

2.1 ROLES 

This section defines the roles involved in the Control Authority operations including the CA itself. 
For the purposes of this document, the scope of the Control Authority is limited to Member 
Agency Control Authority Offices (i.e., exclusive of the CCSDS Secretariat and CA Agent). 

2.1.1 Member Agency Control Authority Office (MACAO) 

The organization responsible for the The- functions of registering, archiving, and distributing data 
object descriptions upon request. Th e organization re s pon s ibl e for th e s e function s- i s a M e mb e r 
Ag e ncy Control Authority Offic e (MACAO): A MACAO may be both a user of and supplier of 
C A functions. When an RP Originator or Requestor interacts with the MACAO, the MACAO is 
clearly a supplier. When two MAC AOs are interacting, one is a user and the other a supplier. An 
example of a MACAO is the JPL Control Authority Office within NASA. 

2.}. 2 RP Originator 

An individual or organization that prepares data object descriptions to be registered with a 
MACAO. The data object descriptions, or metadata, describe data being collected and used within 
the scientific community. An RP Originator may be a producer of the data objects, or acting to 
support producers of data objects. The distinction between the two roles is that the producer is 
responsibly for the data, whereas the RP Originator is responsible for the metadata. An example of 
the producer/RP Originator distinction follows. 


A Principal Investigator (PI) is responsible for a science instrument. The PI designs the 
instrument, collects scientific data, and archives the data. Therefore, the PI is the producer of the 
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data. The definition of how to interpret the data from the instrument is placed under the control of 
the MACAO, possibly by the PI or an associate acting as the RP Originator. The RP Originator is 
responsible for the definition of and registration of these metadata, and will be contacted by the 
MACAO should any issues arise. 

Another example of the producer/RP Originator roles is: a researcher uses existing data objects 
initially collected (i.e., produced) by someone else to produce new data objects or information. 
The metadata objects describing this new data are then registered with a MACAO by this researcher 
acting as the RP Originator. 

There are two variations on the RP Originator role that are derived from the nature of the metadata 
object (MDO) being registered. If the MDO is intended to describe a targeted set of data objects, 
the RP Originator has the responsibility of revising the MDO when the RP Originator determines 
that the MDO does not adequately describe the targeted set of data objects. The other variation 
occurs when the MDO being registered is intended for use by other data producers to create data 
objects that conform to that MDO. The RP Originator is providing metadata that may be referred to 
by many data objects unknown to the RP Originator, therefore he has responsibility for indicating 
that the metadata are not subject to changes. 

Changes to the metadata may only be made by the RP Originator or other individual or organization 
that the RP Originator designates. This person or organization is called a Revising Authority, and 
is identified when the metadata are registered. 

2.1.3 Requestor 

4 

An individual or organization that requests registered metadata from a MACAO. The Requestor 
may also be a consumer of data objects or acting in support of consumers of data objects. The 
distinction is that the consumer is concerned with the actual data whereas the Requestor is 
concerned with the metadata. An example of this distinction is a scientist (i.e., consumer) wanting 
to analyze a particular set or sets of data objects. The MACAO is contacted by the Requestor to 
acquire data descriptions (metadata objects) for the data objects of interest 
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2.1.4 Ascendant MACAO 


The higher level organization to which a MACAO is responsible for its operation. The ascendant 
MACAO provides the authorization for the descendant MACAO, and defines the procedures the 
MACAO must follow. The ascendant MACAO also assumes the archiving and distribution 
responsibilities of any descendant MACAOs as necessary. An example of an ascendant MACAO 
is the primary MACAO for a Member Agency m e mb e r ag e ncy . For status reporting purposes, the 
CCSDS Secretariat and the CA Agent are also ascendant organizations, positioned at the top of the 
CA organization [Ref. 1]; however, they do not function as MACAOs as described in this Report. 

2.2 KEY TERMS 

This section provides a description of the primary information exchanged between the MACAO 
and its interfaces. Definitions (consistent with the P2 glossary) for s om e of these terms may be 
found in the glossary in Annex B. The descriptions in this section provide insight into the use and 
internal composition of the exchanged information. 

2.2.1 Registration Package 

A Registration Package (RP) is an instance of a data object description, that may refer to other 
registered data object descriptions, and that is intended to be registered with a MACAO. An RP 
Originator submits the RP to the MACAO as part of a registration request 


The RP is comprised of an Information Identification Metadata Object (II MDO) and one or more 
descriptive MDOs. The II MDO provides high level information about the RP. These latt e r 
descriptive MDOs will often be a data description record (DDR), a data entity dictionary (DED) or 

common - us e within oth e r RPs. Th e r e fore, any Any given RP may logically incorporate 
previously registered MDOs by reference. A prominent example would be a widely used DED 
which is registered by itself, and is referenced by other RPs. When registered, the collection of 
MDOs contained in the RP are given a single unique an identifier called the Authority and 
Description Identifier (AD ID). 
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2.2.2 Data Description Package 


A Data Description Package (DDP) is the assembled package of MDOs disseminated in response to 
a request for a/i MDO identified by a unique ADID. This may be structured in SFDUform. single 
ADS) . MDOs in the package may all have been registered together (i.e., included) and only 
retrievable id e ntifi e d by the single requested Authority and Description Identifier (ADID) of the 
including MDO, or they may be MDOs that are explicitly referenced by their ADIDs within the 
single (originally) requested MDO ADID . Although an ADID is assigned to an RP when it is 
registered, a request, using that ADID as the key, is for an MDO. The reason for this is that some 
information in the RP will not be included in the DDP, since it has to do with the submission of the 
MDOs. It is the MDO (that is, the RP minus unnecessary administrative information) that is 
requested. Note that the entire package is itself called an MDO. Th e DDP i s an Standard 
Formatt e d Data Uni t (SFDU) which contains on e or more D e scription Data Unit s (DDU sf . 


In general, the MDOs of a DDP may be a DDR, a DED, or other related supplementary description 
information. The DDR is information which describes the producer's data object syntactically. 
The DED is information which provides the meaning (semantics) of data entities in the producer's 
data object. The related information may be other semantic information such as rules and 
constraints among data entities, aggregations of data entities, test data metadata, or external 
references such as contact information or publications. Construction of the DDP might require 
incorporation of MDOs which had been previously registered, and whose contents were not 
included in the RP having the ADID being requested. These Referenced MDOs may or may not be 
stored at the MACAO to whom the request was submitted. If the Referenced MDOs are not stored 
by the MACAO receiving the original request, communications between that MACAO and the 
one(s) at which the MDOs are stored will be necessary in order to completely fill the request. The 
information is exchanged as a DDP in SFDU form, composed of all the MDOs required. Some of 
th ese MDO s will have b e en includ e d - (wh e th e r previously regist e red or not) in th e ori g inal RP th a t 
form s the basi s - for- tins DDP, and oth e r s may only have b ee n ref e renced fr om within this RP. 
(Not e : R e f e r e nc e d MDOs ar e r e f e renc e d by th e ir ADID s , and - thu s must hav e b ee n p re viou s l y 
r e gist e red. - ) The MACAO provides the DDP to a Requestor to complete a successful request The 
DDP contains all of the relevant information supplied by the RP Originator (i.e., the description 
information and some of the identification information supplied by the RP Originator) when- the 
m e tadata was regist e re d, as well as plus the MDOs which were referenced explicitly in the original 
RP and requested for inclusion by the Requestor. If any of the Referenced r e f e r e nced MDOs 
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themselves have Referenced r e f e r e nc e d MDOs, the "references within references" will hqi be 
included in the DDP; those MDOs would have to be requested separately. 

2.2.3 Status Reports 

Status reports consists of r e port s of the information r e gi s t e red registration and of request activity 
information for each MACAO. Status report information is provided to an ascendant MACAO by 
each descendant MACAO according to procedures defined by the CCSDS in reference [1 }. 
Repons c ov e r topics may include including : 

a. Stored data 

descriptive data for all registered MDOs* 

b. Registration activity 

number of requests to register metadata 

number of unfilled requests 

number of RPs accepted (MACAO AD IDs assigned)* 

number of MDO revisions made * 

summary of MDOs registered* 

c. Requestor distribution activity 

number of requests for registered metadata* 
number of unfilled requests 
number of DDPs generated (partial and complete) 
number of DDPs distributed* 

* 

summary of widely-used MDOs* 

d. MACAO interchange 

number of metadata requests from other MACAOs* 
number of DDPs received per source MACAO 
number of unfilled requests 

* Required in the Annual Report by reference [1]. 
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2; 2. 4 MDO Exchange s 


MDOs are e xchang e d betw ee n MACAO s in order that r e qu es ts may b e compl e t e ly fill e d. A 




2.2.4 Technical Support 

With the exception of exchanges of MDOs (i.e., DDPs) described in Section 2.22, all interaction 
between MACAOs is a purely local option. The kinds of exchanges that may occur include: 
updates on changes in local procedures, lists of recently registered or revised MDOs, software to 
assist in daily MACAO operations or to support use of an MDO, assistance in resolving problems 
related to a DDP. 
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3.0 CONTROL AUTHORITY FUNCTIONS 

There are three functional interfaces in which the Control Authority functions are exercised. Figure 
3.0-1 shows those functional interfaces from the perspective of one MACAO (the shaded box). 
They are: 


- intra-MACAO 

- inter-MACAO (i.e., MACAO to (external) MACAO) 

- MACAO to (external) user 



Figure 3.0-1. MACAO Functional Interfaces 

Each of the functions described in the following sections helps defines one of the three functional 
interfaces. Each function is identified in terms of the as b e ing intra- or inter-MACAO, or MACAO- 
user functional interfaces. 
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The MACAO has three major responsibilities: 1) to register data descrip tion s received from RP 
Originators; 2) to distribute data descriptions upon request; and 3) perform administrative 
functions to support responsibilities 1) and 2). All MACAO functions must be consistent with the 
CCSDS Recommendations reference [1J [Ref. 1] . Figures 3.0-2 and 3.0-3 provide a high level 
view of the CA functions. 

The following sections do not assume any particular level of automation in the Control Authority 
operating environment; many of the functions could be performed in a compl e t e ly manual as well 
as an automated environment. However, using automation may make the accomplishment of a 
given function more accurate, timely, and manageable. Annex C contains a list of capabilities that 
are underlying the functions in the following sections. These capabilities are mapped against 
general levels of automation of potential CA operating environments. It becomes clear in this chart 
that some level of automation is necessary to support some of these capabilities. Annex D contains 
a reference to an existing example of a Control Authority that processes and distributes data 
descriptions through an automated interface. The specific implementation is not the focus; it is 
provided as an alternative using automation. - Ann e x E co n tain s an Entity R e lationship diagra m-fer 
the-Contr ol Authority op e rations and a d e tailed d es cription of the data e ntiti es . 

3.1 ADMINISTRATIVE FUNCTIONS 

The administrative functions fall into the following categories: 

Activity Monitor 

- File Management 

- Procedures Definition and Change Control 

- MDO Change Control 

- User Support Services 

- Metadata Integrity & Access Control Data S e curity 

These functions are briefly described in Figure 3.0-2. The following subsections describe each 
function in more detail. Note: These are possible functions. Most are not required by CCSDS 
Recommendations. The functions that ar e TBD [highli g ht e d ^ are required by CCSDS 
Recommendations are marked with an asterisk . 
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ADMINISTRATIVE FUNCTIONS. 


Activity Monitor 

- Provide status to ascendant MACAO* 
Maintain log of RP Originator/ 
Requestors 


Procedures Definition and Change Control 

- Define detailed procedures 

- Update local procedures 

- Define RP information content 
Define DDP request information content 

- Maintain history of procedures changes 

- Make knowledge of changes available 

User Support Services 

- Assist metadata registration process 

- Assist registered metadata request 
process 

Familiarize users with procedure 
Maintain 'lessons learned' 

- Assist user in interpreting DDPs 


File Management 
Maintain lists 

- Maintain database of registered 
int e ractio n MDOs* 

Maintain log of DDPs and RPs* 
Maintain database of tools 

MDO Change Control 

- Manage changes to registered 
MDOs 

Inform RP Originators/ 
Requestors of changes 


Metadata Integrity & Access Control 
Provide metadata after to 
authorized release date only* 
ttjvfj i/iii y 

- Protect metadata from corruption 
Ensure backup and recovery 


Figure 3.0-2. Control Authority Functions - Administrative 
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REGISTRATION FUNCTIONS 

- Provide procedures 

- Evaluate RPs 

- Register data 

- Notify RP Originators 


DISTRIBUTIO N FUNCTIONS 

- Provide request requirements 

£qmb 

xunn 

- Process requests 

— Obtain ref e renc e d MDQ s 

- Prepare DDPs 

- Send DDPs 

- Provide additional information 


QUERY AND R EPORT FUNCTIONS 

Obtain status of request 

Obtain list of newly registered metadata 

Obtain list of newly revised metadata 

- Obtain new procedures 

- Obtain list of ADIDs that have been 
referenced 

Figure 3.0-3. Control Authority Functions - Registration, Distribution, Query and Reports 
3.1.1 Activity Monitor 

The MACAO logs information about its interactions in order to provide upward reporting. Activity 
monitoring functions are inter-MACAO; they are: 

provide status to ascendant MACAO or CCSDS Secretariat* 
maintain log of RP Originator/Requestor interaction 

The CA procedures require an Annual Report ann u al r e p ort by the CA Agent detailing CA services 
and available products. Each MACAO will be responsible for providing that information to the 
next higher level, or ascendant, MACAO. 
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By logging all request activity, a MACAO can generate counts of and statistics on its interactions 
with RP Originators and Requestors. Examples of information required are found in Section 
2.2.3. The minimum set of information maintained must be consistent with reference [1J GGS&S 
R e comm e ndations [R e f. - lj ; however, a MACAO may keep additional records as requested 
r e quir e d by its primary MACAO or local office. 

3.1.2 File Management 

A MACAO is responsible for archiving information both for eventual distribution to Requestors 
and to enhance its ability to locate information needed by Requestors or other MAC AOs. To do 
this, it must have information on hand that allows it to locate MDOs maintained controll e d by other 
MACAOs and to maintain the information for which it is responsible. File management functions 
are all is-an in tra- MACAO function . 

The functions pertaining to file management are: 

- maintain lists of RP Originators/Requestors/other MACAOs 

- maintain a database of registered MDOs* 
maintain a log of DDPs and RPs* 

- maintain a database of tools 

Each MACAO will maintain a list of the RP Originators that who have requested registration or 
revision of metadata, and the addresses of other MACAOs. It will also keep a list of Requestors 
who have requested information from the MACAO. These lists will allow the MACAO to reach 
these organizations as necessary and also to provide their addresses to other organizations that may 
need them. 

Each MACAO maintains a database of its registered MDOs, which comprise the key set of Control 
Authority controll e d information. A registered MDO is identified by its Authority and Description 
Identifier (ADID). The database includes information describing each registered MDO, the creation 
date, and revision history. It also includes a request history, indicating that it was how oft e n - an 
MDO wa s r e qu e st e d and included in a DDP. 
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The MACAO, as a local option, may also serve as a repository of tools (either actual software or 
references to software) this may be software to facilitate building, parsing, and interpreting SFDUs 
or references to software that may be useful or necessary for handling data (e.g., in the analysis of 
data referenced by an MDO or in transmitting large volumes of data). These tools will have been 
registered in accordance with the (TBD) procedures established for CCSDS both regular and third 
party software formats. 

3.1.3 Procedures Definition and Change Control 

The CCSDS defines standard procedures in reference [1J for the operation of the MACAO. These 
procedures allow leeway for the local MACAO to provide additional detailed procedures for its 
interactions. The first five functions of the CA in defining procedures below are intra-MACAO; 
the last is both inter- MACAO and MACAO-usen 

define detailed procedures for registering and requesting metadata 

- update local procedures 

define the information needed for Registration Packages registration packag es 

- define the information needed to request metadata object descriptions 
maintain history of procedures changes 

- make knowledge of changes in procedures available to other MACAOs and users 

Specifics of interaction between a MACAO and its users are defined by the local MACAO. The 
local MACAO defines how required information is to be received from an RP Originator and 
Requestor. Such information consists of instructions on the minimum acceptable required content 

4 

(per CA procedures) cont e nt to prepare, and how and where to send it. The local MACAO may 
request other information as well. Standard forms could be developed for RP registration requests 
and for DDP requests. These forms could be automated and distributed electronically as a CA 
service. 

An ascendant high e r lev e l MACAO will inform a local MACAO of changes to CCSDS standard 
procedures. The local MACAO then informs its descendant l owe r l e v e l MACAOs of the changes. 
These changes will be incorporated into the detailed procedures defined for RP Originators and 
Requestors in whatever way the MACAO sees appropriate, as long as it is conformant. The lower 
level MACAOs provide feedback to the ascendant MACAO, acknowledging implementation of 
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changes and assessing the impact of the changes. The history of the changes in procedures, as 
well as the documentation of the way the changes were implemented will be maintained at the 
MACAO originating the changes. Knowledge of all changes in procedures and implementations of 
those changes should be made available to other MACAOs and users. In this way, the effective 
date of a procedure change can be used to help identify how an RP was constructed and where the 
metadata are if there is any problem with a DDP. If a local MACAO makes any changes in 
procedures, they must not impact conformance with the standard Control Authority Procedures. 

The scope of procedures includes the registration and change control of third party software which 
might be used for internal CA operations, or made available to users. It also includes inter- 
im AC AO exchange procedures. 

3.1.4 MDO Change Control 

The MACAO is responsible for performing change control of registered MDOs and informing 
appropriate parties of the changes. Functions pertaining to change control are: 

- manage changes to registered MDOs 

- inform existing RP Originators/Requestors of changes 

Managing the changes is an intra-MACAO function; informing users is a MACAO-user function. 
MDOs which have been registered are labelled as revisable or non-revisable. An MDO is marked 
non-revisable to ensure changes do not occur which would affect past and present users of the 
MDO in a data generation process. Similarly, consumers are assured that such MDOs arc always 
applicable to the associated data objects. Producers whose data objects are subsequently found to 
be inadequately described by, or in conflict with, the MDO must address this through redistribution 
of the data in conformance with the MDO, or with a new associated MDO that describes the data 
object correctly. This new MDO must also be registered, and will receive a new AD ID. 

A registered MDO is marked revisable if modifications expanding or clarifying the use of the MDO 
are allowed. If the MDO is changed it would keep the same ADID, but receive a new revision 
number. It is the responsibility of the data object producer to ensure that revisions to the metadata 
improve the overall accuracy and completeness of description of the associated data object, without 
impacting the data generation process. Data object producers should be very cautious about 
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adopting existing registered MDO s, when that are marked revisable? for their own use, since the 
MDQ RP Originator may revise such MDOs. This may not be as risky to be attempted, however, 
if the new producer reaches an appropriate agreement with the RP Originator. 

If a valid request to modify a revisable MDO is received, then the MACAO will register the new 
MDO as a revision. Both the original as well as all previous the revision(s) are maintained. 

Notification of revisions to MDOs in the CA Annual Report and local reporting will be a 
mechanism to inform prior Requestors that an MDO has been modified. This is necessary to 
ensure that any erroneous interpretations of data can be corrected. Local MACAO tracking of 
Requestors will allow direct notification of specific Requestors;-, it will be a local MACAO option 
whether to broadcast the notification or send it to each affected Requestor. 

3.1.5 User Support 

The MACAO provides support to assist user interaction with th e MACAO ; they are all MACAO- 
user functions. User support functions of the MACAO are: 

- assist RP Originators in preparing and submitting RPs r e gistration packag es 

- assist Requestors in preparing and executing requests for DDPs 

- familiarize users with procedures 

- maintain 'lessons learned' 

- assist users in interpreting DDPs 

The MACAO will provide support to RP Originators in all steps of registration — starting with 
identification of an appropriate MACAO with which to register the metadata. This support may be 
accomplished in a number of ways. The MACAO will make all necessary registration information 
available to the RP Originator in a timely fashion. Support will be provided in the way of guidance 
and feedback via phone, facsimile, or electronic media if appropriate, for each stage of the 
registration process. Forms may be provided (electronic or hardcopy) with supporting 
documentation on how to use them. Samples of correctly completed registration packages may be 
available to the RP Originator. A MACAO may maintain a 'lessons learned' log based on user 
problems. A user's guide may be available; it would include one or more detailed registration 
scenarios. 
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Similarly, the MACAO will provide support to Requestors for submitting a request for registered 
information. Assistance will be available for filling out forms; feedback and guidance will be 
provided by phone, facsimile, or electronic media. The MACAO will help the Requestor identify 
and locate the appropriate MACAOs if additional querying is necessary. The MACAO will provide 
instructions on accessing packages of registered information that reside on multiple media. The 
MACAO may keep a list of ADEDs that Requestors have had problems with, and may also inform 
the Requestor if a requested ADID should nd be used due to some previously reported problem. 
After the Requestor has received the DDP, the MACAO will assist, if needed, in interpreting the 
structure of the DDP. The MACAO will also serve as a liaison between RP Originator(s) and 
Requestors), if the RP Originators are still in existence. 

The MACAO will provide support for users in learning and following procedures. There may be 
user's guides that clearly identify the sequence of actions and current contacts for the major 
functions involved in the registration and request for registered metadata. The MACAO will keep 
this documentation current. In addition, a hotline type of support may be provided to walk the user 
through more detailed questions. 

The implementation of the user support will be dependent on the specific environment created by 
each MACAO. However, some of the specific user support capabilities function s that could be 
included in an automated environment are: 

- online tutorial for using the automated registration function 

availability of languages/compilers received from producers for scientists/users to use 

t 

display of field values for all previously entered metadata to minimize redundant 
metadata entry 

3.1.6 Metadata Integrity and Access Control 

The MACAO protects the integrity of the information controlled at its office. These are entirely 
intra-MACAO functions. Functions pertaining to metadata integrity and access control are: 

provide registered metadata after release date only* to authorized users only 

- protect registered metadata from corruption by limiting access 
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- ensure integrity through backup and recovery procedures 

In general a MACAO provides registered MDOs to Requestors upon request. User security 
requirements, and their enforcement, are up to the RP Originator user. Under CCSDS procedures, 
m ^ MD0 wUl not be disseminated until the release data is exceeded; no other circumstances 
prevent its dissemination unexpired release date prevents the diss e mination of an MDO . The 
procedures for enforcing physical security are outside the scope of CCSDS services; there is no 
CA liability. 

Registered metadata is protected from corruption. Only the personnel designated by the local 
MACAO can directly access the registered metadata under the MACAO's control; these personnel 
are responsible for maintaining the integrity of the archived metadata content. Requestors of 
MDOs must interact with a combination of automated processes, and possibly personnel, to 
acquire registered metadata. The MACAO may invoke automated processes to change, update or 
create metadata sets for dissemination. 

A MACAO is responsible for protecting its metadata from permanent loss or problems which may 
affect the quality of the metadata. Consequently the MACAO develops procedures and implements 
safeguards to protect the metadata. Backup procedures will be established and adhered to by the 
local MACAO. Recovery procedures will be invoked whenever necessary to return the MACAO to 
normal operations following data loss or interruption of service. 

3.2 REGISTRATION FUNCTIONS 

The MACAO has a major responsibility to register data descriptions as requested by RP 
Originators. The first and fourth functions are MACAO-user, the second is both intra-MACAO 
and MACAO-user, and the third is intra-MACAO. The functions involved in registration are: 

- provide procedures and input requirements and/or forms to RP Originator 

- evaluate Registration Packages received 

- register the metadata 
notify the RP Originator 
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A MACAO provides procedures to RP Originators to help them prepare Registration Packages. 
The MACAO may provide the RP Originator with a means of submitting information that 
submission form to ensures that registration requests are uniformly prepared. The MACAO may 
assess completeness and quality of RPs received. This will include checking for the existence of 
Referenced MDOs, whether they are stored locally or not. The MACAO checks whether all 
required identifying information is received. RPs which are accepted are assigned an ADID, and 
the MACAO's database is updated. RPs which are rejected are returned to the RP Originator; the 
MACAO may also choose to maintain this information. The MACAO informs the RP Originator of 
the disposition of the RP. 

Test data may be included in the RP as a descriptive MDO containing as supplementary 
information. A consumer of this registered metadata could check out his implementation of the 
metadata against the sample test data before it is applied to the full set of scientific data. 


The MACAO will not guarantee the correctness of a registered data description; however, the 
MACAO will help to resolve problems experienced with its registered metadata. If the Requestor 
of a DDP does not notify the MACAO of a problem with the registered metadata, then the MACAO 
takes no action. Upon notification by a Requestor that a DDP was unusable, the MACAO will first 
check if any problem exists with the DDP as generated and sent by the MACAO. If no problem is 
found with the DDP generation or transmission, the MACAO will contact the RP Originator of the 
original RP. The MACAO will work with the RP Originator to find and resolve the problem. If 
the RP Originator (or producer) is unavailable, the MACAO may be unable to help the Requestor. 
If the problem is corrected, the RP Originator or Revision Authority may submit a Revising 
Registration Package to replace, or correct, the revisable MDO. A new DDP is generated by the 
MACAO, sent to the Requestor, and the success/failure of this DDP is monitored. If necessary, 
the MACAO will repeat the steps required to correct the problem. 

3.3 DISTRIBUTION FUNCTIONS 

The MACAO has a major responsibility to provide MDOs as requested. The functions pertaining 
to distribution are: 

- provide request requirements and/or form to th e Requ e stor 

- process the request received 
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- prepare the Data Description Package (DDP) 

- send the DDP 

provide additional information as appropriate 

The first function is MACAO-user; and the fourth and last functions is are MACAO-user; or inter- 
MACAO and the second is intra-MACAO , and third is are inter-MACAO and intra-MAC A O r and 
t he- last - 4 s - an int e r MACAO function . The MACAO works with the Requestor to complete his 
request. The MACAO may provide a request form or screen to help make the request consistent 
and complete. The MACAO evaluates the request and informs the Requestor of the request's 
status. 

The MACAO acquires the requested MDOs from its own files, or directs the request to another 
MACAO if necessary and from oth er- MACAO s as n e c es sar y. A separate request is required for 
each registered MDO the Requestor wants — unless the additional registered MDO is referenced 
within the requested MDO. The MDOs are assembled as a DDP; the DDP is prepared construct ed 
as an SFDU in accordance with the structure and construction rules in reference [3J. If the DDP is 
to include Referenced MDOs from some other MACAO, the DDP(s) for that Referenced MDO 
would first be received by the MACAO receiving the original request. Then that/those DDPs 
would be incorporated into the DDP; the DDP, when fully constructed, will be sent to the 
Requestor. The only exception to this statement is if any of the MDOs have a release date that has 
not been exceeded. Th e DDP is s e nt to the Requ es to r ; If the Requestor has a problem with the 
information contained in the DDP, he contacts the MACAO to help resolve it (as described above in 
Section 3.2). Acquisition of any other information, such as the status of non-released MDOs, 
MACAO reports, or problem reporting is based on Requestor contact with the MACAO. 
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3.4 QUERY AND REPORT FUNCTIONS 

The MACAO has a major responsibility to make information about metadata available to users and 
other MACAOs. The kinds of query and report functions that the MACAO may provide are: 

obtain status of request 
obtain list of newly registered metadata 
obtain list of newly revised metadata 
obtain new procedures 

obtain list of ADIDs that have been referenced 

The MACAO will, as a result of normal operation, have the above information available in its local 
database. The MACAO should provide some interface that allows users to easily provide 
parameters (e.g., date, keyword, ADID, submitter's name) for any of the above standard 
queries/reports. If there are repeated requests for another type of query/report, the MACAO may 
include new "canned" queries in its local software. 


ISSUE-1 


PAGE 3-13 


1/15/91 



DRAFT 


CCSDS REPORT - CONTROL AUTHORITY OPERATIONS 
4.0 SCENARIOS FOR CA OPERATION 

The following sections provide illustrative scenarios of interaction between the MACAO and other 
organizations. These scenarios are: 

1) MDO Registration 

2) Obtaining Registered Information 

3) Status Reporting R e portin g Statu s 

4) DDP Exchange between MACAOs 

5) Registered MDO Revision 

6) Running Queries and Reports 

These scenarios provide an overview of CA operations necessary for an understanding of the CA 
functions. 

The format of each subsection is as follows: 

- high level textual description 

- participants ( roles) in the scenario 

- major steps in the process 

scenario that d e scrib e s th e action/respons e tak e n - by th e CA and the oth e r organizatio n 
in both graphic and textual formats 

Each scenario represents a set of actions/responses between two participants (roles) organizati ons 
Th e s c e narios are presented both graphically and in text The graphical presentation is a one page 
flow of numbered boxes containing the major scenario actions, numbered in the sequence of 
occurrence, and without regard for which participant performs the action. The participants' views 
are accomplished by separating the sequences of actions that each performs . Th e text di s cu ss io n of 
e ach numb e r e d box i s pr ese nt e d in two columns corre s ponding to e ach participant's "vi e w" o f t h e 
s c e nario. Th e two vi e w s of the scena rio are ac c omplish e d in th e gmphi e al flow by se parating th e 
se qu e nc e- of actions p e r participant, regardless of box numb e ring. — Th es e Each participant's 
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sequences of actions are connected by directional arrows b e we e n th e box es. The text discussion 
of each numbered box is presented in two columns corresponding to each participant's "view" of 
the scenario. Again, the sequence of the scenario is preserved using the same numbers as in the 
graphical flow. 

The scenarios presented in this section are intended to capture the basic functions of the MACAO 
and the user. The method of presentation may give the impression of a lot of interaction. It is 
expected that many of these functions can, and will, be automated, thereby minimizing the amount 
of manual or verbal interaction. 


Also, each step of a scenario is not necessarily required for each session between two participants 
e ntiti es. Some steps may not need to occur at all or may carry over from previous interaction. For 
example, it is not expected that instructions for submission will need to be repeated for the 
experienced user. 


The figures in this section are used to display information content contained in requests and 
messages between a MACAO and its users. These figures are constructed to appear as "forms." 
However, this is not intended to imply or recommend the use of paper forms, or even a specific 
representation of the information, for interaction with a MACAO. The information could be 
represented on computer screens, using menu options, or on paper forms. Annex D, in fact, 
presents a CA system that uses very different possible interface. 


The figures in Section 4.0 contain examples of data inputs (blank figures can be found in 
Appendix E ¥). The input is provided solely to demonstrate what (type of) information might go 
where; no attempt is made to explain the information or provide a context for it Th e sourc e o f 



for ms in this s e ction i s th e Contr el- 

and Di ss emination Conc e pt Paper (TOU/Q0/P2/N00 8 ), d es cribing 
NASA/JPL Control Authority sy s tem. Specifica lly, the RP i s pr es en te d in Section 7.1 ef- th a t 
nnd th e DPP in S e ction 8- .S - . The specific meaning of each field on the form is defined 
in the Data Element Dictionary in Annex F. That annex also contains an Entity-Relationship 
diagram for Control Authority operations. 
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4.1 MDO REGISTRATION 

MDO Registration is the process by which an RP Originator registers the metadata with a MACAO. 
A possible scenario follows. 

4.1.1 Description of MDO Registration 

In order for organizations and individuals to use data produced by other organizations, a 
description of that data (along with other related information) must be made available. To facilitate 
the long term preservation and exchange of such descriptions, they may be registered with a 
Control Authority organization. To perform the registration, the MACAO requires, at a min imum, 
identification information and data description information such as a definition of the data format 
(the DDR) of the data of interest. From the perspective of the MACAO, the individual or 
organization that registers the description data, or metadata, is the RP Originator. The RP 
Originator may also be the producer of data, or a representative of the producer (e.g., a project 
office) or a representative of the broader science/user co mm unity 

The RP Originator may identify the appropriate MACAO by contacting the CCSDS CA Agent, 
contacting any MACAO or selecting the MACAO from a CA report. He requests instructions on 
how to submit his registration request and receives instructions on how to supply the 
presubmission information, and what that information is. Figure 4.1-1 is an example of the 
information required for RP Presubmission Information. The information in this figure may be 
supplied manually (i.e., verbal or written) or electronically, depending on the respective individual 
capabilities of the MACAO and RP Originator. After the RP Originator submits the Presubmission 
Information, there may be some discussion to clarify the way in which the RP Content can be 
extracted from the RP about to be submitted. It may be that for a given MACAO, there is always a 
predefined way information is to be supplied, or that for a given RP Originator the information is 
only supplied once. This prevents unnecessary submission of the Presubmission information. 
Determining the nature of this interaction is entirely up to the local MACAO. 
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MACAO Name 

MACAO ID 

ADID (if revision) 

Lee M. Johnsen 

NJPL 



Date of Submission (yyyy-mm-dd) 

Registration Identifier 

1 990-01 :26T1 3:1 5:20. 123 


LMPXYZDED0001 

RP Originator's Name 
Lee M. Phelps 

RP Originator's Affiliation 

Jet Propulsion Laboratory 


RP Originator's Mailing Address 

MS-264-728; Jet Propulsion Laboratory, 4800 Oak Grove Drive, Pasadena, CA 91 109 


RP Originator's Electronic Mail Address 


TELEMAIL: LPHELPS 
Brief Title for RP Content (s 40 characters) 


XYZDED 


Proposed Media and Protocol for RP Content 


A) Electronic Transfer 

i Text 

Binary 

Telemail 


C) 3.5* Diskette (IBM) 

_ 720 KB 
1.44 MB 


B) _ 3.25* Diskette (Macintosh) D) jL 5.25* Diskette (IBM) 
_ 800 KB j 360 KB 

1.4 MB 1.2 MB 


G) Other 


Location of RP Content on Proposed Media 

A) RP Content will be message content . 

B) - E) jf XYZDED 

(File Name) 


E) Bernoulli Cartridge 

5.25’ 10 MB 

8.0" 20 MB 


F) 0.5" Magnetic Tape (9 Track) 

6250 BPI 

1600 BPI 

800 BPI 


F) File Location on Magnetic Tape 

G) Other: 



Figure 4.1-1. Sample Registration Package (RP) 


Presubmission Information 
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The MACAO tracks the various pieces of information related to the Registration process with a 
registration identifier. This identifier is provided by the RP Originator to allow the two parties a 
means of tracking a specific request for registration; the local MACAO may establish the nature of 
this identifier. As an example, this registration identifier may contains the submitter's initials 
nam e, brief tide and/or a sequence number. 

The RP submission information needed to register a data description is presented in Figure 4.1-2. 
The RP Originator prepares up to three sets of information, identified as Part 1, 2 and 3 in the 
figure. The Identification Information MDO (Part 1) contains the information related to the 
management of the RP, such as the RP Originator's originator- s name and address, brief title, 
description of the RP, and the Revising Authority if different from the RP Originator. The ADIDS 
of any Any Referenced r e f e r e nc e d MDOs ADID s appearing in the remainder of the RP Part 3 may 
be listed by the RP Originator MACAO , purely as a convenience, to facilitate creation of the fer 
wh e n th e DDP fet this RP will b e cr e at e d . Part 2 contains the information for each description 
MDO to be registered as part of (i.e., included in) this RP. Each of these MDOs is identified with 
respect to what interpretation language will be used to as to how it i s interpret it int e rpret ed (which 
corresponds primarily to CCSDS ADIDs) and the type of information it contains (which 
correspond to classes of metadata). The information in Part 2 is repeated for each MDO included 
in the RP. If art the MDO in Part 2 requires a previously registered non-CCSDS MDO for its 
interpretation, the its ADID of that MDO is supplied. Part 3 contains explicit references (using 
ADIDs) to previously registered MDOs which are necessary for this RP to be complete. This 
includes any non-CCSDS MDOs required by ADID , fef an MDOs included in Part 2. Only the 
ADIDs of the first level of Referenced ref e renc e d MDOs ADID s (ie?, those MDOs to be ADID s 
included in the DDP for this RP in Part 3 ) are is to be included in the RP. Each successive level of 
RP will provide the ADIDs of the next lower level Referenced ref e renc e d MDOs ADID s. There is 
no need to include the full description of the Referenced re f e renc ed MDOs ADID s. The 
Referenced referenc e d MDOs ADID s should be indicated using the syntax, e.g., "DDR = " or 
"DED = ". In all cases (whether Referenced ref e renc e d MDOs are maintained by local or other 
MACAOs), existence of the Referenced ref e renc e d MDO ADI D will be checked for upon 
registration. The latest revision vefsien of the Referenced ref e renc e d MDOs will be included in the 
DDP at time of dissemination. 
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Registration Package" (RP) Submission Information 


Part 1. Identification Information MDO 


Page of_ 


MACAO ID 
NJPL 


ADID (if revision) 


Registration Identifier 

LMPXYZDED0001 


MACAO Name 
Lee M. Johnson 


Date of Submission (yyyy-mm-dd) 
1 990-01 :26T1 3:1 5:25. 123 


Revision Number (Optional) 
1 


Brief Title (< 40 characters): 
XYZDED 


Brief Description (100-200 characters) of RP Content or RP Content Revision 

This data dictionary contains the vocabulary used to describe the data sets for experiment XYZ of the Mars Observer 
Project 


Revision Type (select one) 
Revisable CNon-Revisabia 


Release Date (yyyy-mm-dd) 
1991-01-01 


Test Performed (Select one) Test Data MDO Included (Select one) (Optional) 


Yes 


RP Originator's Name 


Yes No 


RP Originator's Affiliation 
Jet Propulsion Laboratory 


RP Originator's Mailing Address 

MS-264-728, Jet Propulstion Laboratory, 4800 Oak Grove Drive, Pasadena, CA 91 1 09 

RP Originator's Electronic Mail Address 

RP Originator's Telephone Number 

TELEMAIL: L PHELPS 


Revising Authority Name (it other than RP Originator's) 

Revising Authority's Affiliation 

(SAME) 


Revising Authority’s Address 
* 

Revising Authority’s Electronic Mail Address 

Revising Authority's Telephone Number 

Referenced MDO MACAO ADIDs (list all): 


NJPLKL13, NJPLKL1 2, NJPLL014 


Referenced MDO CCSDS ADIDs (optional): 


CCSD0001 , CCSDO000, CCSD0002, CCSD0004 



Figure 4.1-2. Sample Registration Package (RP) Submission Information 
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Registration Package (RP) Submission 


Page of. 


Part 2. Description MDOs (one block per MDO, repeat as necessary) 


Content Language Interpretation Language 

English (CCSD0002) 

PVL (CCSD0006) 

TSDN (CCSD0007) 

DED Structure (CCSD0008) 

V Other (non-CCSDS) ADI * NJPLL014 

Type 

Catalog 

DED 

DDR 

i Supplementary 
Test Data 



Internal Tracking Number 
TAR001 


MDO Content 


This is where supplementary information would be found that would allow a user to interpret the Registration 
Package. This particular RP is a DED that will be referenced by other TLVO structures of the Mars Observer 
Project. 

Since the dictionary itself is to be found separately in a Class-E header, supplementary information that explains 
how to use what is in the Class-E header could be placed here. 

Sample topics: 

1 ) What the text format is for the dictionary - 
e.g. keywords names being in column t 

definitions begin in column 10 
each line ends with an EOL delimiter 

2) What tools are included for using the dictionary 

3) How to use those tools 

4) What other tools are available elsewhere 

5) What other DEDs relate to this one 

6) How often the dictionary is updated 


Relationships with other MDOs (if applicable) 

TAR001 precedes TAR002 
TAR001 describes TAR002 


Figure 4.1-2. Sample Registration Package (RP) Submission Information (Continued) 
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Registration Package (RP) Submission 


Part 2. Description MDOs (one block per MDO, repeat as necessary) 

, J L - . . . i _ 


Page. 


of 


Content Language Interpretation Language 

i English (CCSD0002) 

PVL (CCSD0006) 

TSDN (CC3D0007) 

DED Structure (CCSD0008) 


Other (non-CCSDS) ADI = 


NJPLLaii 


Type 


Catalog 

DED 

DDR 

j Supplementary 
Test Data 


Internal Tracking Number 
TAR002 


MDO Content 

albedo 

eccentricity 

flattening 

obliquity 

radiance 


"Reflectivity of a planetary surface or particle" 

"A measure of the extent to which the shape of an orbit deviates from circular* 

"A measure of the geometric obfateness of a solar system body, defined as the ratio of the 
difference between the body's equatorial and polar diameters to the equatorial diameter, or 
(a-c)/a* 

“Angle between a body's equatorial plane and its orbital plane" 

"A measure of energy radiated by an object. EXAMPLE: ’spectrumjntegratedj’adiance'* 


Relationships with other MDOs (if applicable) 

TAR002 follows TAR001 
TAR002 isjjescribed_by TAR001 


Figure 4.1-2. Sample Registration Package (RP) Submission Information (Continued) 
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Registration Package (RP) Submission 


Part 3. References to Previously Registered MDOs 


ADIDs of Referenced MDOs 


ADI * NJPLK013 
ADI * NJPLK012 
ADI - NJPLL014 

ADI = CCSD0001 
ADI = CCSD0000 
ADI - CCSD0002 
ADI * CCSD0004 


MDO Relationships (if applicable): 


NJPLL014 isjanguagejor NJPLK013 
NJPLL014 isjanguagejor NJPLK012 


Figure 4.1-2. Sample Registration Package (RP) Submission Information (Concluded) 
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The potential complexity of the RP lies within Parts 2 and 3. Since there can be multiple MDOs 
included in an RP, and conceivably each of these could have one or more Referenced r e f e r e nc e d 
MDOs AD CD s, a means of correctly relating all the appropriate pieces of the RP is necessary. To 
support this, each description MDO included in an RP (whether it was previously registered or not) 
will have an internal tracking number;.— In the case of a previously r e gist e r e d MDO, this id e ntifi e r 

develop a local standard for creating this identifier. Relationships among and between the MDOs, 
included in Part 2 of the RP could be captured as shown in the bottom of Figure 4.1-2 (Part 2). 
Relationships between MDOs included in Part 2 and Referenced r e f e renc e d MDOs AD IDs could 
also be captured in Figure 4.1-2 (Part 3). The full set of relationships is not defined in this 
document nor at this time ; a very initial cut at some possibilities are included in the sample forms. 


If an RP Originator wants to make an individual MDOs in Part 2 of the RP accessible 
independently from the RP in which it is included, he must submit the ea c h of th ese MDOs as a 
separate RP with its own II MDO. It will then receive a unique AD ID. The ADID , which will be 
recorded in Part 3 2 of the "main" RP as a Referenced MDO if the MDO is not included. 



Sample test data may be included in the RP (as an MDO in Part 2) to become part of the registered 
MDO. These test data will be included to allow the Requestor/consumer to try out his 
implementation of the data description on actual data with known results. However, the MACAO 
is not responsible for the quality of the test data. The MACAO also does not verify that the test 
data works. 


The RP is sent to the MACAO via the means of communication negotiated with the receiving 

4 

MACAO. The MACAO records the receipt of request and then evaluates the RP for completeness 
and correctness with respect to its submission criteria. An RP acknowledgement/disposition, 
which includes the results and/or status of the RP evaluation, is sent to the RP Originator within 
five working days. The acknowledgement/disposition has the information as presented in Figure 
4,1-3. The MACAO also attaches and returns a copy of the submission information when the 
disposition is other than "Under Review." 
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Acknowledgement/Disposition of Receipt of Registration Package (RP) 


(Filled out by MACAO) 


WPLXYZf 



RP OfiglnattH** Mam* 

i Date of Response CW»)wriiTKW) 

| 

Lae M. Phelps 

1 1990-01 :3G¥ 





j Accapted IAD1D Assigned* 
Undaf Review: Expected Pat* of 
Compietfwi 


• Submitted *0 Incpi^MAdA^ 

111 111 aw . pHIII 

. .• • — 

Expfanafioft of 1. 


Coolings ndae described 
RP S^misotOft Form; ||| 
tn Explanation of Cgniingendae 
(Rwgbrrttto register RP) 




Figure 4.1-3. Sample Acknowledgement of Receipt of Registration Package (RP) Information 
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If the review is incomplete, the MACAO provides an expected date of completion. If the RP 
would be accepted with some changes proposed by the MACAO, this information is described in 
the acknowledgement. The RP Originator can determine if he agrees with the proposed changes 
and resubmit the modified RP (or have the MACAO effect the modifications). 

If the registration request is rejected, the RP Originator is informed of the reason; he may then 
correct the problem and resubmit the RP. 

If the RP is accepted, the MACAO assigns it an overall AD ID. The MACAO stores the registered 
information in its database. The local MACAO has the option whether to store the information in 
SFDU format or not. The MACAO informs the RP Originator when the RP was accepted, 
registered, and stored. Prior to the release date the RP Originator may submit changes to the 
registered MDOs, identifying them by the ADID. (See Section 4.5, Registered MDO Revision) 
The MACAO publishes availability notices of the registered MDO to other MACAOs after the 
release date had been reached. 

4.1.2 Participants in MDO Registration 

Participants in the registration of metadata are the MACAO and RP Originator. The RP Originator 
initiates the registration activity, defines the metadata, and generates the RP; the MACAO provides 
as much help as necessary to ensure the successful registration. 

4.1.3 Major Steps in MDO Registration 
The major steps in the scenario for registration are: 

- Request/response for process information 

- Preparation/submission of RP 

- Evaluation of the RP 

- Registration 

- Notification 
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4.1.4 MDO Registration Scenario 


The flow for the MDO registration scenario is presented in Figure 4. 1-4. The text associated with 
this graphic representation of the flow of the scenario follows immediately. 


RP Originator 

1 . Selects MACAO. Select appropriate 
MACAO by either 

contacting the CA Agent 
- selecting from the CA Annual Report 
contacting any MACAO 

2 . Request RP Instructions and Form. 
Depending on the media used by the MACAO 
for the RP instructions and forms, and the ease 
of access the RP Originator has to one of these 
media, the RP Originator will either ask the 
MACAO to send the materials or be able to 
access them directly. 

4 . Receive and Return Presubmission 
Information. Fills out Presubmission Informa- 
don and makes it available in whatever manner 
agreed upon with the MACAO. (This may be 
done once per RP Originator, not per RP) 


6. Prepares RP Submission Information. 
Supplies the II MDO, and one or more MDOs 
comprising the balance of the RP content 
.Test data resul ts may also be included. 

7 . Sends RP to MACAO. The method for 
sending the RP will have been agreed upon 
previously. 


MACAO 


3. Provide RP Instructions. 
Instructions will include the specific 
requirements for filling out the various 
parts of the RP Presubmission and 
Submission Form. 


5. Signs off on Presubmission Info. 

Concurs with presubmission information. 
A copy of the Presubmission Information 
is returned to the user with the status. 
May require discussion with the RP 
Originator to clarify understanding of the 
input before the MACAO signs off. 


8. Evaluates RP. The RP will be 
examined for completeness, clarity, 
and validity. The referenced MDOs are 
checked for their individual status. 
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RP Originator 


10a. Revises RP. The problems causing non- 


13. Receives Acceptance Notice. Approval 
of the RP and assigned AD ID will be 
acknowledged to the RP Originator. 


MACAO 

9. Dispositions RP. The MACAO 
provides status of the RP to the RP in 
Originator. The RP is either: 1) held up 
in review, 2) contingently accepted, 3) 
rejected due to problems or 4) accepted. 

If case 1), the expected date of 
completion is provided. If case 2) or 3), 
the RP Originator may revise the RP 
based on explanations of the problems 
provided by the MACAO in the 
Acknowledgement/Disposition notice. 
Step 10a follows at the discretion of the 
RP Originator. If case 4), the MACAO 
goes on to approval in Step 10b. 

10b. Approves RP. After one or more 

Evaluatio n-cycle, the RP is approved and 
Acknowledgement/Disposition 
notice is prepared. 

11. Assigns AD IDs. The RP is 
assigned an ADID and acknowledgement/ 
disposition is completed. 

12. Updates Database/Sends 
Acceptance. All new informadon 
contained in the RP will be added to the 
MACAO’S database. 

14. Provides Notification of 
Registration. In a bulletin board manner, 
announcement of the RP approval and 
key identifying information will be made 
available in the medium of the MACAO's 
choice to all other MACAOs. 


4.2 OBTAINING REGISTERED INFORMATION 


This section describes a scenario for acquiring registered information where a Requestor needs the 
metadata to allow a consumer to interpret a dat set 
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4.2.1 Description of Obtaining Registered Information 

A science researcher typically correlates, analyzes, and processes existing data sets to produce new 
data sets that provide scientific revelations. In order to read data produced by another organization, 
the researcher (or consumer) must know how it is encoded. The MDOs containing the data 
description (i.e., the metadata) that permit this to be done are expected to be registered with a 
MACAO. 

When SFDU labeling Recommendations are followed, the consumer should be able to identify the 
ADID for the metadata. The ADED provides the identity of the MACAO, as well as the local MDO 
identifier for the drat metadata. The researcher contacts the MACAO, provides the ADID, and 
requests the associated information. 

In the eyes of the MACAO, this consumer is a Requestor of previously registered information. 
The MACAO identifies the information needed to process the request (see Figure 4.2-1, Request 
for Registered Information). 

The Requestor completes the request and submits the information to the MACAO. To request 
more than one registered data description, the Requestor must provide separate requests. In the 
case of RPs that have been revised, the latest revision will be the default for dissemination. The 
Requestor should provide the revision number with the ADID if other than the most recent revision 
is desired. To learn of new revisions, a Requestor can check periodic reports or ask the MACAO 
periodically. [NOTE: The current Structures and Construction Rules do not support revisions 
explicitly.] The MACAO evaluates the request. The Requestor is informed of the status of his 
request by receiving an acknowledgement (see example in Figure 4.2-2) from the MACAO. An 
individual acknowledgement is provided for each request 

The MACAO may reject the request if the MDO has not reached its release date or incomplete or 
incorrect request information is received. The Requestor is informed of the MACAO'S inability to 
provide the requested information in the acknowledgement; the Requestor can then revise the 
request as appropriate. 
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Request for Registered Information 


MACAO 10 
NJPL 


MACAO Name 
Lee M. Johnsen 


Requestor's Name 

Larry Shotland 


Requestor's Mailing Address 
GSFC, Building 8, Room 234, Greenbelt, MD 20771 


Requestor's Electronic Mail Address 
NASAMAIL: LSHOTLAND 


NJPLXYZ1 


Date of Request (yyyy-mm-dd) 
1 990-05:1 8T1 5:32:1 6.572 


Requestor's Affiliation 
SAR/STX 


Revision Number 

Exclude all Referenced MDOs MACAO 

(Optional) 

ADIDs (select one) ^ v 

Yes C No ^ 


ADIDS (select one) 


Exclude the following Referenced MDOs for the requested ADID (list ail ADIDs of MDOs to be excluded) 



Preferred Media and Protocol for DDP 




A) Electronic Transfer 

C) 3.5* Diskette (IBM) 

E) 

Bernoulli Cartridge 

Text 

720 KB 


5.25" 10 MB 

Binary 

1.44 MB 


8.0" 20 MB 

Telemail 




B) 3.25* Diskette (Macintosh) 

D) _j£_ 5.25* Diskette (IBM) 

F) 

0.5* Magnetic Tape (9 Track) 

800 KB 

J_360 KB 


6250 BPI 

1.4 MB 

1.2 MB 


1600 BPI 




800 BPI 

G1 Other 




Comments 
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Acknowledgement of Request for Registered Information 


(Filled out by MACAO) 


Requested AtJED i. 1'. 

Date of Reeporae ^yyy*mrtHJd) 

IliMliiliigil 


NJFtXYZt 

f99O.05:23Tlb:40:lO:S3 

illl 

NJPi 


OOP Release (Select one) 
(Jes) No Partial 


MACAO AOID/Anflcipated Release Date (If Partial) 


JI 


Re aeon tor Non* Release 


Transfer Media and Protocol for DDR 

A) Electronic Transfer 

Text . 

Binary . 

Tefemalf 


B) _ 3.25' Diskette (Macintosh) 
_8Q0KB 
1.4 MB : 


C) _ 3.5* D&k9tte(!8M) 

720 KB 

' _ 1.44 MS 


D) Diskette (IBM) 

X3MK8 II 
1.2 MB 


BwmbuS Cartridgell 
«&ti ___20MB 


P) _ 0.5* Magnetic Tape (3 Track) 
_ 6230 BP! ; .■ 

• _i6Q0Bpi . 

800 BPI ' 


'M 




Loc^ton of MD<> <w. 

A} fee messegi* extent || 

Bt*s) J& :S:,^ Y2^,l3r” 


§§ 

M 


fiie Name) 
Otfietl 








Figure 4.2-2. Sample Acknowledgement of Request for Registered Information 
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Generally, all MDOs referenced (by their AD IDs) within a requested AD ID will be provided along 
with the requested AD ID. For the Referenced re ferenc e d MDOs A BED s, the MACAO will acquire 
the MDOs from each appropriate MACAO as necessary. If any of the Referenced referenced 
MDOs AD IDs have been revised, the latest revision will be the one sent to the Requestor as a 
default. Any revised MDOs will hopefully cause no problem; it is the Requestor's responsibility to 
track down any problems. The Requestor may indicate that he does not want to receive this 
additional information in the request information. The sample request in Figure 4.2-1 allows the 
user to exclude all or specific referenced ADEDs. 

Once the request is accepted, the MACAO builds a Data Description Package (DDP) which 
includes all the metadata requested. This DDP will include the II MDO and all the data description 
MDOs. The most recent revision of each MDO, including the Referenced re ference d MDOs, is 
included, unless specific previous revisions were requested. The revision number is part of the 
distribution. 

The MACAO logs the distribution of the DDP with the Requestor’s name attached. 

The MACAO sends the DDP to the Requestor re qu e stor . The Requestor reads the DDP and 
determines if the package is sufficient or if additional MDOs are needed. If it is not sufficient, or if 
he needs help to overcome a problem, he requests additional information from the MACAO. A 
problem report, as shown in Figure 4.2-3, can be filed with the MACAO. Any additional request 
for registered information will follow this same scenario. 

4.2.2 Participants in Obtaining Registered Information 

Participants in obtaining registered MDOs are the MACAO and the Requestor. The Requestor 
initiates the activity by requesting the registered information; the MACAO provides as much help 
as necessary to ensure the request is met 
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DDP Problem Report 


Requested ADID 


Date DDP Received (yyyy-mm-dd) MACAO Name 


MACAO ID 


Date of Problem Report Submission 
(yyyy-mm-dd) 


DDP Requestor's Name (Blank if same as Submitter) 


Problem Report Submitter's Name 


Submitter's Affiliation 


Submitter's Mailing Address 


Submitter's Electronic Mail Address 


Description of Problem (including procedures used that led to identification of problem) 
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4.2.3 Major Steps in Obtaining Registered Information 

The major steps in this example scenario for obtaining registered information are: 

MACAO Identification 
Request/response for process information 
Preparation/submission of request 
- Evaluation of the request 

Preparation/distribution of the Data Description Package 
DDP assessment 


4.2.4 Obtaining Registered Information Scenario 


The flow for the obtaining registered information scenario is presented in Figure 4.2-4. The text 
associated with this graphic representation of the flow of the scenario follows immediately. 


Requestor 

1 . Examine Data. A data set that is 
wanted is examined. Per CCSDS 
recommendations, the AD ED for the metadata 
is in a fixed location in the SFDU label(s). 

2. Extract AD ID. The ADID is read. It will 
identify the appropriate MACAO 

and provide die MDO identifier. 

3. Query MACAO. The Requestor 
-will contact the MACAO for assistance in 
requesting the registered information. 


MACAO 


4. Provide Data Request Instructions. 
The MACAO will assist the Requestor in 
the process for requesting registered 
information. The MACAO will identify 
the appropriate request information. 


5 . Receive Request If there are any 
questions regarding the request information, the 
Requestor will contact the MACAO. 

6. Prepare Request. Using as much detail 
as possible, the Requestor will fill out the 
request. The Requestor may wish to indicate 
which referenced MDOs are not wanted. 
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REQUESTOR VIEW 
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Figure 4.2-4. Obtaining Registered Information Scenario Flow 
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Requestor 

7 . Send Request Information. The 
Requestor will send the completed request 
to the MACAO. 


10a. Revise Request. The Requestor has 
the option of revising the request based on 
comments from the MACAO and 
re-submitting the revised DDP request 
Step 6 and following will be repeated. 


MACAO 

8. Evaluate Request. Each piece of 
referenced information in the request will 
be checked for release date and 
availability- This may require 
coordination with other MACAOs. One 
of three dispositions will be rendered: 
approved, rejected, or partial. 

9a. Reject Request. The request cannot 
be accommodated; a reason for the non- 
approval will be provided to the 
Requestor and acknowledgement 
returned. If the request is rejected, step 
10a follows. 

OR 

9b. Approve Request The approval 
may be complete or partial. If it is partial, 
the MACAO will identify those MDOs in 
the request that cannot be forwarded until 
their designated release date. 
Acknowledgement is returned. If 
approved, step 10b follows. 

10b. Prepare DDP. The MACAO 
assembles the DDP by accessing the 
requested MDO by its-ite AD ID plus all 
referenced and related MDOs. For MDOs 
to be acquired from other MACAOs, see 
Section 4.4 scenario "DDP Exchange 
Between MACAOs." 

1 1 . Send DDP. The complete DDP will 
be sent to the Requestor. 


1 2. Assess DDP. The Requestor will 
evaluate whether the package contains what he 
requested and if anything else is needed or 
wanted. 
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Requestor 

1 3. Request Additional Information. If the 
Requestor has problems with the registered 
metadata, he contacts the MACAO and may file « . 
DDP Problem Report Requests for additional 
information require submission of another 
request form. 


15. Requestor Comment. The Requestor 
may choose to express concerns, problems, 
or praise to the MACAO about the process 
for obtaining registered information. 


MACAO 

14. Provide Additional Information. 
The MACAO helps resolve problems 
with the registered metadata, and contacts 
the RP Originator if necessary and 
possible. 

The MACAO responds to requests for 
additional MDOs through the process 
described in this scenario. The MACAO 
also encourages feedback regarding the 
interaction process with the Requestor. 


4.3 STATUS REPORTING REPORTING STATUS 


Status Reporting R e po t tin g sta t u s is the process by which a lower level MACAO provides details 
of control activity to a higher level MAC AO. A possible scenario follows. 


4.3.1 Description of Status Reporting R e portin g- Statu s 


A MACAO provides service to RP Originators and Requestors re qu e sto rs of data descriptions 
primarily as described in the scenarios in Sections 4. 1 and 4.2. The CCSDS Secretariat requires 
reports of the level of activity of registration and distribution. Consequently, each descendant 
MACAO reports information to its an ascendant MACAO. The current minimum set of 
information to be reported is defined in reference th e Control Authority Proc e dur es [R ef . [\ ] . 
However, additional information may be required locally and requested by an ascendant MACAO. 
In order to support this reporting requirement, each MACAO will need to produce statistics as 
described below. 


The local MACAO maintains counts of the requests to register metadata. Separate counts of 
rejections and acceptances are made. The number of revisions is counted. The local MACAO 
maintains counts of the requests for registered metadata. Likewise, separate counts of the 
approved and rejected requests are made. A MACAO may keep records on the reasons for 
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rejection. Requests from MACAOs are distinguished from requests from other users. The 

MACAO assesses MDOs widely used and identifies which are candidates for becoming standard 
CCSDS objects. 

Each year, according to the CA Procedures, this information is tallied and provided in a standard 
report that is summarized for each Member Agency. The MACAO also provides a list of all 
registered metadata stored in the local database. The list includes the ADID and tide of the MDO. 

Intermittent requests for current reports or updates to the annual yearly report may occur. A 
MACAO would respond with an ad hoc report. Each primary MACAO might define additional 
report formats and reporting schedules as it they deems necessary. 

4.3.2 Participants in Status Reporting Reporting Status 

Participants in the reporting of status are the local MACAO and its next higher level CA 
organization. 

4.3.3 Major Steps in Status Reporting Reporting Status 

The major steps in the scenario for reporting status are: 

- Report request 

- Data access/analysis 

- Local report generation 

- Upward report generation 

4.3.4 Status Reporting R eporting Status Scenario 

The flow for the Reporting Status scenario is presented in Figure 4.3-1. The text associated with 
this graphic representation of the flow of the scenario follows immediately. 
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ASCENDENT MACAO VIEW 


rssirF-i 



PAHP 


1 n 5/Q1 


Figure 4.3-1 Status Reporting Scenario Flow 
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Ascendant MACAO 

Local MACAO 


l^ ReqUeStReporL ^ther it is the annual 
report or an intermittent ad hoc report, the 
office issues its request. 


2. Receive Report Request. The 
request is received; the local MACAO 
acknowled^s and determines the due 
date and format of the report. 

3. Determine Report Contents. The 

S?hi fi h C « rCp0rtrc< ? uircraents '’ which may 
be the basic annual set or additional 

miormauon, are determined. Any 

”o'sT«So 8 n h ' “ ““ ndam 

4. Access Data. The MACAO will 
query the database for both archived 
information (such as lists of holdings 
organization structure) and request 
activity information (such as RPs 
received and registered, new AD IDs 

revised, DDPs created 
and distnbuted, information exchanged 
between MACAOs, and widely used 

5. Generate Statistics. The various 
counts and/or lists will be produced. At 
minimum this includes the counts of 
request activity parameters to deteimine 
volumes of information and levels of 
activity. Analysis of frequent requests 
for certain MDOs is performed leading to 
recommendations for CCSDS 
standardization. 

6. Build Local Report The 

information compiled or calculated is put 
into the report format dictated bv the 
ascendant MACAO. 7 

7 . Send Report Using the medium of 
communication determined by the 
ascendant MACAO (but preferably 
Jfp™ “ Predefined format), the local 
MACAO will forward the completed 
report 
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Ascendant MACAO Local MACAO 

8 . Acknowledge Report Receipt Upon 
receipt of each Descendant MACAO report, an 
acknowledgement will be provided. The 
ascendant MACAO will verify all information is 
included as requested. 

9. Synthesize Inputs. The various local 
MACAO reports will need to be combined in a 
meaningful way for continued upward 
reporting. The MACAO will include its own 
archived and activity information. 

10. Send Report Upward. The report is sent 
to the requesting MACAO. In this process the 
ascendant MACAO now functions as a 
descendan t- D e sc e nda nt MACAO with respect to 
reporting. 


4.4 DDP EXCHANGE BETWEEN MAC AOs 


Data exchange between MACAOs is the process by which a MACAO acquires the metadata it 
needs to respond to a request when some of that metadata is under the control of a different 
MACAO. A possible scenario follows. 


4.4.1 Description of DDP Exchange Between MACAOs 

A MACAO receives requests for registered metadata as described in the scenario in Section 4.2, 
Obtaining Registered Information. The request is for a given MDO; the ADID points to the 
responsible (primary) MACAO. However, there may be references to other MDOs whose AD IDs 
point to different, (secondary) MACAOs. The primary MACAO will have the responsibility of 
obtaining tracking down these additional MDOs by contacting the secondary MACAOs. 

The primary MACAO issues a request for a given MDO or set of MDOs by providing the ADID to 
the appropriate secondary MACAO. The requested MDO is provided to the p rimar y MACAO in 
the form of a DDP. 
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If a Requestor's request includes information not under control of a CCSDS Member Agency, the 
local MACAO may provide the external authority's contact information, or attempt to track down 
the information. This decision is at the MACAO'S discretion. 

The primary MACAO is responsible for compiling all the requested information into a DDP - 
including any external authority contact information that may have been received. The medium of 

exchange for the DDP is negotiated between the primary MACAO and the user, as well as between 
the primary and secondary MACAO(s). 

4.4.2 Participants in DDP Exchange Between MACAOs 

The participants in the data exchange process are any two MACAOs. 


4.4.3 Major Steps in DDP Exchange Between MACAOs 


Major steps in the data exchange process are: 

- Identification of MACAOs 

- Contact MACAOs 
Response 

- DDP Preparation 


4.4.4 DDP Exchange Scenario 


The flow for the data exchange scenario is presented in Figure 4.4-1. The text associated with this 
graphic representation of the flow of the scenario follows immediately. 

Pri ™'3' MACAO Secondary MACAO 

1. Read Referenced ADIDs. Embedded in a 
Requestor's request may be references to MDOs 
(identified by ADIDs) controlled by other 
MACAOs. Each unique other MACAO ID is 
extracted, and is associated with the AD ID. 
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FIGURE 4.4-1. Data Exchange Between MACAOs Scenario Flow 



draft 

CCSDS REPORT - CONTROL AUTHORITY OPERATIONS 
Primary MACAO 

I Secondary MACAO 

2 . Identify Appropriate MACAOs. Using 
latest annual report containing the complete 
CA organization, the MACAO identifies V 
the other (secondary) MACAOs access 
mechanism. 

Contact MACAOs. The primary MACAO 
usina?h imUmCate eac ^ secondary MACAO 

Send ADIDs. The primary MACAO u/in 

JJS®! ? ne or morc A DED 3 identifying MDOs 
needed from the secondly iN^CAO ^ JVUJUs 
providing their ADIDs^ ^ 

I 

MACAo'i.ll’i ADIDs ,. The “condajy 
MACAO will accept the ADIDs for the 

MDOs that are under its control. 

<5. Assess MDO Availability. Just as 
• w I th “)[ oriier request for MDOs, the 

f ™, CA0 re ^ uest win be assured 
for compliance with procedures for 
release. 

7. Prepare and Send DDPs. The 
secondary MACAO will collect and 
compile all the MDOs that have been 

,?? UeStC . d ^P rcparc ** explanation of 
whyan MDO cannot be supplied. The 

MDOs/ responses are packaged as a DDP 

^w^ADE and sent id the [nimay 

8 Receive DDPs. Within the 5 days of 
the ongmal request, the MACAO 
should receive all MDOs from each of the 
MAC* 0 *- If not, the MACAO 

Tte MACAoSn ^ W”* *«Poiue. 

9. Prepare Composite DDP. When the 
requested MDOs arTreceived, the MACAO 
packages them into a composite DDP together 

reaue^^ rcgistered ^° s for 
requested See scenano in Section 4.2 

Obtaining Registered Information", step 10 b. 


ISSUE -1 


PAGE 4-31 


1/15/91 



DRAFT 


CCSDS REPORT - CONTROL AUTHORITY OPERATIONS 
4.5 REGISTERED MDO REVISION 

The process for revising MDOs that have already been registered is described in this section. 

4.5.1 Description of Registered MDO Revision 

The SFDU concept assumes that MDOs to be registered will not require frequent revisions. 
Information that has a known dynamic nature is assumed to be exchanged within the labeled data 
object itself, not through MDOs registered with MACAOs. However, the need to revise MDOs 
exists. Revision of registered MDOs parallels the basic registration process described in Section 
4.1, MDO Registration. 

The interaction occurs between the MACAO and another party (either the RP Originator or 
Revising Authority) attempting to register a data description. The MACAO evaluates the RP for 
inclusion as a registered MDO. However, in this case, the data description in the RP has been 
previously registered. 

4.5. 1.1 Types of MDOs 

The revision process is governed by the type of MDO to be registered and the point in the life cycle 
of the MDO. The types of MDOs are: 1) an MDO that describes a specific set of data objects and 
2) an MDO that will be used by other data producers to create objects that conform to that MDO. 

The first type of MDO is created for a specific labeled data object The producer of the labeled data 
object or an RP Originator acting for the producer, prepares the description and submits the MDO 
as an RP to a MACAO. This MDO may be revised any time at the discretion of the RP Originator 
and/or Revising Authority. It would be marked "revisable" in the RP Submission information (see 
Figure 4.1-2). An example of this type of MDO would be a DDR geared for a specific 
instrument's data. If the data description needs to change due to improved understanding of the 
instrument's operation or to account for an error, a revision to the MDO would be beneficial to all 
users. At any time, the RP Originator may change the MDO from revisable to non-revi sable. For 
a more detailed discussion of the application of this type of MDO see example User Scenario 1 in 
Annex G. A particular consideration that should be taken is using a status of revisable for MDOs 
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that might be referenced from within another RP. If an MDO gets revised and the revision's 
implication is not known to a submitter referencing the MDO, there is some level of risk of 
incompatibility between the metadata and data. 

The second type of MDO is a multi-use description to which many data producers may conform in 
the preparation of their labeled data objects. These MDOs should not change. They would be 
marked "non-revisable" in the RP Submission information (see Figure 4.1-2). An example of this 
type of MDO is a DED which may be incorporated by reference into descriptions of other data. An 
update to this DED, such as adding new terms, would be registered as a new DED with a new 
ADED. The original DED remains available from the MACAO. At no time can a non-revisable 
MDO be changed to revisable. For a more detailed discussion of the application of this type of 
MDO see example User Scenario 2 in Annex G. 

All MDOs to be registered will have a "release date" specified by the RP Originator. This date may 
be any time from the time of registration to a future date. This information is noted in the RP 
Submission Information (see Figure 4.1-2). Until the release date is reached, a registered MDO 
would not be provided to Requestors. Any MDO may be revised before the release date; 
however, only an MDO registered as "revisable" may be revised after its release date has passed. 

4.5. 1.2 Life Cycle of MDOs 

The two types of MDOs described above, specific and multi-use, undergo different life cycles. 
The respective life cycles for each of the types of MDOs appear in Figure 4.5-1 and 4.5-2. 

For a specific MDO, the initial MDO may be defined before the labeled data objects it is to describe 
is defined. Therefore the correctness of the initial MDO may be very uncertain. This MDO will 
likely go through a testing phase which may lead to changes. At some future time, labeled data 
object production software or processing software may need to be generated and then a registered 
ADID for the MDO may be needed for incorporation into the software. Revision one of the MDO 
is generated. At this point the MDO is revisable, but not releasable. Additional testing may occur 
leading to other changes. Those changes will not result in a revision number change, but will need 
to be tracked by the RP Originator. (R e vision I) . At some point in time the MDO describing the 
labeled data objects has reached a stable state and can be released for access by the general 
community of potential labeled data object users (Revision 1 X). Although it is releasable, it still 
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TIME AXIS 


TESTING PHASE 


-STABLE PHASE ► 


INITIAL MDO 

MDO REGISTERED: 

REVISION 1 
• Revisable 
- Non-releaseable 


MDO MDO 

RELEASED: REVISION Y 

REVISION 1 
• Revisable 
- Releaseable 


Figure 4.5-1. Life Cycle for "Specific" MDOs. 


TIME AXIS 


TESTING PHASE 


•STABLE PHASE 


INITIAL MDO 

MDO REGISTERED: 

REVISION 1 

- Revisable 

- Non-releaseable 


MDO 

RELEASED: 
FINAL 
REVISION X 
• Non-revisable 
- Releaseable 


Figure 4.5-2. Life Cycle for "Multi-Use" MDOs. 
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may be revised Updates ,o the regisiered MDO may sdll be required to maintain the best MDO 
needed to descnbe all the labeled data objects produced in the past as well 1 ^ 

to be produced in the future (Revision Y). ’ U '° Se “ DC!paKd 


dau object in' ^al^"", 0 ^ 

it, zzz, z ““‘‘rr^T 

this point it can not be revised even bv the RP Ori,ri„„ , Restore. At 

. . . ceo. even by the RP Originator, since unknown data producers mav be 

^mg on and can not afford to have i, changed Any derired changes must be reflected in a lew 
MDO which would receive a new ADID. rccca in a new 


4.5. 1.3 Revision Process 

To rev.se a registered MDO, the Revising Authority (or the RP Originator) contacts the MACAO to 

offing - ^ ^ Auihomy * *«*--- m— 

of die ^ I 2 rKlmred by "* ™» information wifl include the ADID 

of the MDO to be revtsed inclusion of the ADA) idendfles the RP as a request for a revision 

7 MACA0 — - *» — 

and the Revision T™. ft, ■ • ^ ' the Revmn * Authority name, the release date, 

the Rev. s, on Type of the ongtnal (previous) revision and whatever other measures seem 

appropriate. If the request is made by anyone other than the RP Originator or ZZ1ZZ 

i:rrr ^ be ASSUm “* Atuhority is conecu and 

e release date has not been reached the revision will be allowed If the release date has passed 
the revision will be allowed only if the Revision Type is "Revisable". 
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The MACAO provides the disposition of the revision request to the Revising Authority. Assuming 
the revision is allowed, the Revising Authority prepares a revised RP containing the changes. This 
RP will be substituted for the previous Revision of the MDO in its entirety, since the MACAO will 
be unable to make changes internal to the MDO. The revision RP contains the same basic 
information as presented in Figure 4. 1-2, RP Submission Information, but with the ADID filled in. 
The revision RP is sent to the MACAO. 

The evaluation and disposition of the revision RP follows the same process as the MDO 
Registration scenario in Section 4.1. The MACAO evaluates the revision RP for completeness and 
correctness with respect to its submission criteria. An RP Acknowledgement/Disposition, which 
includes the results and/or status of the RP evaluation, is sent to the Revising Authority within 5 
working days. (See Figure 4.1-3). The RP may be accepted or rejected. If rejected, the reason 
for rejection is provided to the RP Originator ! Revising Authority with the option of correcting the 
problem and resubmitting the revision RP. 

Acceptance of the revision RP results in a new revision number (incremented by one) of the MDO 
with the same ADID. The previous revision of the MDO is also maintained by the MACAO. 

The Revising Authority is notified of the acceptance. The MACAO publishes availability notices of 
the revised MDO after the release date has been reached. 

4.5.2 Participants in Registered MDO Revision 

Participants in the revision of registered MDOs are the MACAO (where the MDO is registered) and 
the Revising Authority. The Revising Authority initiates the revision activity; the MACAO 
ensures the revision is allowed before accepting the changes. 

4.5.3 Major Steps in Registered MDO Revision 

The major steps in the revision scenario are: 

- Presubmission 

- Preparation/Submission 

- Evaluation 
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- Reregistration 

- Notification 


4.5.4 Revision of Registered MDO Scenario 


The flow for the Revision of Registered MDOs scenario is presented in Figure 4,5-3. The text 
associated with the graphic follows immediately. 


Revising Authority 

1. Contacts MACAO. Contacts the 
MACAO that originally registered the MDO to 
be revised. Submits Presubmission 
Information including the ADID of the MDO to 
be revised. 


,4. Prepares RP Submission Information. 
Supplies the II MDO and one or more MDOs 
comprising the balance of the RP Content. 

The Revising Authority may include the reason 
for revision in the Brief Description of the RP 
Submission Information. 

5. Sends Revision RP to MACAO. The 
new revision of the RP is sent to the MACAO. 


MACAO 


2. Receives Revision Request. 
Receives the Presubmission Information; 
noting the presence of an ADID which 
indicates a revision. The MACAO 
accesses the MDO based on the ADID. 


3. Assesses Reusability. Checks the 
name of the revision requestor against the 
authorized Revising Authority and/or RP 
Originator. Checks the release date and 
the Revision Type. Informs the Revising 
Authority whether the MDO can be 
revised. 


6. Evaluates Revision RP. The RP 
will be evaluated for completeness, 
clarity, and validity. The referenced 
MDOs are checked for their individual 
status. 
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Revising Authority 


8a. Revises Revision RP. The problems 
causing non-acceptance will be rectified. 
Step 5 and following will be repeated. 


10 . Receives Acceptance Notice. Approval 
of the revision RP will be acknowledged to the 
Revising Authority. 



MACAO 


7. Dispositions Revision RP. The 
MACAO provides status of the revision 
RP to the Revising Authority. The 
revision RP is either: 1) held up in 

review, 2) contingently accepted, 3) 
rejected due to problems or 4) accepted. 
If case 1), the expected date of 
completion is provided. If case 2) or 3), 
d'd ^ ev ' s * n S Authority may modify the 
RP based on explanations of the 
problems provided by the MACAO in the 
Acknowledgement/Disposition notice 
Step 8a follows at the discretion of the 
Authori ty- If case 4), the 
MACAO goes on to approval in Step 


8b. Approves Revision RP. After one 
eva ^ uation cycles, the revision 
RP is approved and Acknowledgment/ 
Disposition notice is prepared. 

9. Updates Database/Sends 
Acceptance. All new information 
contained in the revision RP will be 
added to the MACAO's database. The 
Revision number will be incremented by 
one. 


1 1 . Provides Notification of Revision. 
In a bulletin board manner, 
announcement of the revision and key 
identifying information will be made 
available in the medium and to the extent 
of the MACAO's choice to all other 
MACAOs. 
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4.6 RUNNING QUERIES AND REPORTS 

Running queries and repons is the process by which RP Originators, Requestors, and other 
MACAOs can obtain current knowledge of information maintained by a given MACAO. 

4.6.1 Description of Running Queries and Reports 

In order for the CA users to get maximum benefit from the system, they should be able to have 
access to current (relevant) information. Examples of things that would be considered relevant are: 
status of a request, lists of newly registered or revised metadata, changes in procedures. Ideally, 
the The users would s hould be able to have direct access to the MACAO'S database for this 
function. 

4.6.2 Participants in Running Queries and Reports 

The participants in this function are the user and the MACAO. The user may be an RP Originator, 
a Requestor, or other MACAO. 

4.6.3 Major Steps in Running Queries and Reports 

The major steps in the running queries and reports process are: 

- Report request 

- Data access 

- Local report generation 
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4.6.4 Running Queries and Reports Scenario! 


The flow for the Running Queries and Reports Scenario is presented in Figure 4.6-1. The text 
associated with this graphic representation of the flow of the scenario follows immediately. 


User 

1 . Request Report Whether it is the annual 
report or an intermittent ad hoc report, the 
office issues its request. 


Local MACAO 

2. Receive Report Request. The 
request is received; the local MACAO 
acknowledges and determines the due 
date and format of the report. 

3 . Determine Report Contents. The 
'specific requirements', which may be the 
status of a request or listing of new RPs, 
are determined. 

4. Access Data. The MACAO will 
query the database based on the user's 
request parameters. 

5. Generate Statistics. The various 
counts and/or lists (if applicable) will be 
produced. Analysis of frequent requests 
(or types of requests) performed leading 
to possible standardization of additional 
local reports. 

6. Build Local Report The 
information compiled or calculated is put 
into the report format determined by the 
local MACAO. 

7. Make Report Available. Using the 
local MACAO system, the local MACAO 
will make the completed report available 
for the user requesting it 


8 . Acknowledge Report Receipt Upon 
receipt of the report, an acknowledgement will 
be provided. 
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USER VIEW 



LOCAL MACAO VIEW 


Figure 4.6-1 Running Queries and Reports Scenario Flow 
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ANNEX A 

LIST OF ACRONYMS 


ADI Authority and Description Identifier 

CA Control Authority 

CCSDS Consultative Committee for Space Data Systems 

DDP Data Description Package 

DDL Data Description Language 

DDR Data Description Record 

DDU Description Data Unit 

DED Data Entity Dictionary 

DIL Data Interchange Language 

U MDO Identification Information Metadata Object 

JPL Jet Propulsion Laboratory 

MACAO Member Agency Control Authority Office 

MDO Metadata Object 

PI Principal Investigator 

PR Problem Report 

P2 Panel 2 

RP Registration Package 

SFDU Standard Formatted Data Unit 
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ANNEX B 
GLOSSARY 


A ”tS? 0: ** ^ >0 Which a MACAO is respond, for „s 

Consumer: A user of daia: a description of the data has been registered with a MACAO. 

“”£SiSS f 2?3!,¥S“?'«ss 

CCSDS Secretariat Overall responsibility rests with the 

Data ° data objects an gUagC (DDL): A f0rmaJ notation for specifying the conceptual structure of 

0311 ^^^ihs^sren^idendfie^^ich^ cahhwi^an 

““ OT DIL ““ - —on necessary to 

Dare Element: The smallest named item or items of dare for a given appUcahon. 

^ E wtch D ^°Sda A retti£ that C0 " ta "" definidons “0 supplementary information 

Data Interchange Language (DIL): A noredon for describing the physical representation of data 
Dare Object: A collection of data elements that are aggregated for or by a specific application. 

DeSC " iP CCSDTsi "* COnmining •*"*” <te describes other data and confer , „ to 

'dentification Morion Meredare Object: The MDO of an RP that contains infotmation about tite 

Cm ^ C au A p1ces of^^CSDS Agency tMmbef^gmey orgariStion! AUth0ri,y ’ Und " ' h ' 
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Metadata Object: An identified collection of metadata. 

Non-revisable MDO: An MDO, registered with a MACAO, that may not be revised once its 

Release Data is exceeded. 

Obtaining Registered Information: The act of requesting an instance of a data description identified 
by its ADI from a Control Authority Office. 

Producer: A generator of data objects whose description is to be registered with a MACAO. 

RP Content: The MDOs comprising an RP, i.e., an II-MDO and one or more other MDOs. 

RP Originiator: That individual or organization that submits the Registration Package to a MACAO 
and accepts responsibility for the RP Content. 

Referenced MDO ADI: T he- ADI of an MDO which a) has b ee n A previously registered MDO that- 
b) is not included in the RP being constructed, which e) is necessary for a complete and 
accurate data description. Its ADID appears in the referencing MDO. 

Registrant: That individual or organization that submits the Registration Package to a MACAO and 
accepts responsibility for the RP content. 

Registration: The act of submitting an instance of a data description to a Control Authority Office 
which is assigned a unique ADI. 

Registration Package: An instance of a data description, that may refer to other registered data 
descriptions, and that is intended to be registered by a MACAO. Registration implies the 
assignment of an unique ADI. The instance is referred to as an MDO. 

Requestor: That individual or organization that requests registered data descriptions from a 
MACAO. 

Revisable MDO: An MDO, registered with a MACAO, that may be revised at the direction of the 
RP Originator or the RP Revising Authority. 

Revising Authority: That individual or organization that has been designated, in the registration of 
an MDO with a MACAO, as having the authority to submit a revision to that MDO. 
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ANNEX C 

CAPABILITIES IN VARIOUS 

CONTROL AUTHORITY OPERATING ENVIRONMENTS 
This annex provides a list of capabilities that a Control Authority might require to perform the 
various CA operations, and whether the capability could be supported in a given type of operating 
environment. The last three columns are identical; however they imply different levels of "power", 
and are therefore all included. 


Operating 

Environment 

Capability 

Manual 

Single 

User 

Micro 

Single User 
Micro With 
Communications 

Mini/Main 

With 

Comm 

Voice Communication 

V 

V 

V 

V 

Mail Communication 

V 

V 

< 

V 

Fax Communication 

V 

< 

V 

V 

Electronic File Transfer 



V 

V 

Online Registration/ 
Request 



V 

V 

Online Tutorials 



V 

V 

Testing 


< 

V 

V 

Problem Reporting 

V 

< 

V 

V 

Data Manipulation 


< 

V 

V 

Data Analysis 


V 

V 

V 

Registration/Request Tracking 


V 

< 

V 

Elimination/Reduction 
of Redundant Data Entry 



< 

V 

Automated Status Report 
Generation 



V 

V 


Automatic Generation of Logs 


Network 


i 

v 

v 

\ 

\ 

i 

V 


V 

< 

V 

< 

V 

V 

V 
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ANNEX D 

AUTOMATED CONTROL AUTHORITY EXAMPLE 


(See "Automated Control Authority Registration Process", 9/07/89, Lee Johnsen, 
JPL, OTT/89/P2/N5 and "Control Authority Scenarios: Registration and 

Dissemination", 2/06/90, Lee Johnsen, JPL, CCSDS Panel 2 Action Item OT-M- 
08). 


W 
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ANNEX FE 

DEFINITION OF MACAO DATA ENTITIES 


An Entity-Relationship diagram is presented for a Control Authority. The tables following the 
diagram provide definitions of the data entities. Each data entity defined is an element that appears 
on the illustration forms for data registration and request included in this document. The table is 
organized alphabetically by data entity; in the case where there is a generic data entity underlying 
the specific usage, the generic entity is enclosed in brackets [ ]. The fortn(s) on which a given data 
element appears are coded with a number. The translation for those codes is: 

1 . Registration Package (RP) Presubmission Information 

2. Registration Package (RP) Submission Information (Part 1) 

3 . Registration Package (RP) Submission Information (Part 2) 

4. Registration Package (RP) Submission Information (Part 3) 

5 . Acknowledgement/Disposition of Receipt of Registration Package (RP) 

6 . Request for Registered Information 

7 . Acknowledgement of Request for Registered Information 

8 . DDP Problem Report 
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Registration Package (RP) Presubmission Information 


MACAO Name 

MACAO ID 

ADID (if revision) 

Da'e of Submission (yyyy-mm-dd) 

Registration Identifier 

RP Originator's Name 

RP Originator's Affiliation 

RP Originator's Mailing Address 


RP Originator's Electronic Mail Address 


Brief Title for RP Content (s 40 characters) 


Proposed Media and Protocol for RP Content 


A) Electronic Transfer 

_ Text 

Binary 

Teiemail 


C) 3.5’ Diskette (IBM) 

_ 720 KB 
1.44 MB 


E) Bernoulli Cartridge 

5.25' 10 MB 

8.0* 20 MB 


B) 3.25’ Diskette (Macintosh) D) 5.25’ Diskette (IBM) F) 0.5’ Magnetic Tape (9 Track) 

_ 800 KB _ 360 KB 6250 BPI 

_ 1.4 MB _ 1.2 MB _ 1600 BPI 

_ 800 BPI 

G) Other 


Location of RP Content on Proposed Media 

A) RP Content will be message content 

8) - E) 

(File Name) 

F) File Location on Magnetic Tape 

G) Other: 

MACAO Acceptance: _ Accepted __ Accepted wim Contingency Not Accepted 














Registration Package" (RP) Submission Information 


Part 1. Identification Information MDO Page of 


MACAO Name 

MACAO ID 

ADID (if revision) 

Date of Submission (yyyy-mm-dd) 

Registration Identifier 

Revision Number (Optional) 

Revision Type (select one) 
Revisable Non-Revisable 

Release Date (yyyy-mm-dd) 

Brief Title (s 40 characters): 


Brief Description (100-200 characters) of RP Content or RP Content Revision 


Test Performed (Select one) 


Test Data MDO Included (Select one) (Optional) 


Yes No 
RP Originator's Name 


Yes 


No 

RP Originator's Affiliation 


RP Originator's Mailing Address 


RP Originator's Electronic Mail Address 

RP Originator's Telephone Number 

Revising Authority Name (if other than RP Originator's) 

Revising Authority's Affiliation 

Revising Authority's Address 
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Revising Authority's Electronic Mail Address 

Revising Authority's Telephone Number 

Referenced MOO MACAO ADIDs (list all): 


Referenced MDO CCSDS ADIDs (Optional) 
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Content Language Interpretation Language 

_ English (CCSD0002) 

_ PVL (CCSD0006) 

TSDN (CCSD0007) 

DED Structure (CCSD0008) 

Other (non-CCSDS) ADI * 


Internal Tracking Number 


MDO Content 


Catalog 

_ DED 
_ DDR 

Supplementary 

Test Data 


Relationships with other MDOs (if applicable) 
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Revision Number 

Exclude all referenced MDO MACAO 

Exclude all Referenced CCSDS MDOs 

(Optional) 
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Yes No 

(select one) 

Yes No 


Exclude the following Referenced MDOs for the requested ADID (list all ADIDs of MDOs to be excluded) 


Preferred Media and Protocol for DDP 

A) Electronic Transfer 
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Telemail 


3.5* Diskette (IBM) 
_ 720 KB 
1.44 MB 


Bernoulli Cartridge 

5.25’ 10 MB 

8.0* 20 MB 


B) _ 3.25* Diskette (Macintosh) 
_ 800 KB 
' _ 1.4 MB 
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Scenarios Involving MDO Use and Update 

Scenario 1: The UARS project has been delegated to be a CAO, and is supporting the UARS 
scientists in the registration of descriptions and dissemination of DDPs. Investigator A creates a 
format description to describe the data as it is expected to appear following launch. He generates 
some test data in this format, and packages it in SFDU labels. Since he has not registered the 
format description, he creates his own ADI by beginning the ADI with a "Z", and packages this 
description with the labeled data. He transfers this product to his colleagues overseas to test their 
preparation to receive the data, and to test his preparation of the product. His colleagues discover 
an error in the description of the format, and so he revises the description. 

Prior to launch the ground handling system, which will actually create the labeled data objects he 
expects, requires the registered ADI for insertion into the labels they will add to the data. In 
addition, his local software contractor also wants this ADI to insert into a table that will be used to 
direct the local data handling and processing software. This software will not use the format 
description directly, but will incorporate this information into its processing algorithms for 
efficiency. Investigator A registers his format description with the CAO, and provides the ADI and 
description to both the ground handling system and the local software contractor. However he 
informs the CAO that his description is not to be released for 4 months, which he expects to be 
about 3 weeks after launch. This should give him time to look at the data and verify the 
correctness of the description before allowing general use. He also advises the CAO that the 
format description must be revisable following the release date. 

The launch is slipped one month, so he requests the CAO to push back the release date of his 
description by one month. 

Following launch, he begins to receive labeled data objects from the ground handling system and 
his local processing software begins to produce garbage. Investigation reveals that there was an 
error in understanding and documenting how the instrument packed information into a particular 8 
bit word. Therefore he has his local software revised, and submits a revised description to the 
CAO which is labeled version 2 and is noted as an important update. The nature of this update is 
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also described. This error is transparent to the ground handling system since it does not look at 
this information to do its processing. 

Following the release date, he begins to send copies of the data to his colleagues and informs them 
that the CAO has a revised description. He has included this description in the initial data provided 
to them. They proceed to fix their software and to make the data available to others locally. 

After about 6 months, Investigator A notices a mis-spelled name for a field in the format 
description. He wants this corrected at the CAO because he is in the process of preparing 
additional information that will refer to that name. This results in version 3 of the description, 
which is noted as having an editorial change. The nature of the editorial change is described. He 
does not bother to inform his colleagues. 

After about 1 year, the instrument suffers a mode failure that results in the periodic occurrence of 
"all ones" in one of the fields of the format. Fortunately this is predictable and describable in the 
following way: For times greater than TO in word 3, the value of word 5 is fill (all ones) when 
word 10 indicates mode=4. This information needs to be added to the format description to 
improve its correctness for all the labeled data objects carrying the ADI of the format description. 
He provides the new description to the CAO as version 4. At the same time he adds a text 
description of the instrument operation and the calibration coefficients to use in converting values 
to physical units. This version is noted to be an important revision from the previous version, and 
the nature of the revision is described. He notifies his colleagues of this new version. Other 
recipients of the data, who are unknown to him, should periodically check with the CAO or check 
the CA Agent Annual Report to see if new revisions version s of the description are available. 
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Scenario 2: The Planetary Data System (PDS) has prepared a Data Element Dictionary (DED) 
that it would like adopted within the planetary community. It decides to register this DED with a 
CAO so it may be readily incorporated by reference into the descriptions of a wide range of data. It 
registers this with an immediate release date, and an update status of non-revisable. In this way 
future data producers can be sure that this DED will not change after they have generated labeled 
data objects and descriptions that may refer to this DED. 

After about 12 months, the PDS has accumulated a set of additional terms to be added to the DED. 
A new DED is created and submitted to the CAO for registration. It receives a new ADI which is 
not necessarily related to the old ADI in any visible manner. PDS advertises the existence of this 
new DED and encourages its use, in place of the older DED, for all new data and descriptions. 
However from the point of view of the CAO, this is just another registered MDO with a 
registration date and brief description that will appear in the annual report. It is up to PDS to 
advertise it as a replacement for new work. 
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Date of Problem Report Submission DDP Requestor's Name (Blank if same as Submitter) 

(yyyy-mm-dd) 

Problem Report Submitter's Name Submitter's Affiliation 

Submitter's Mailing Address 
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ANNEX G 


Scenarios Involving MDO Use and Update 

Scenario 1: The UARS project has been delegated to be a CAO, and is supporting the UARS 
scientists in the registration of descriptions and dissemination of DDPs. Investigator A creates a 
format description to describe the data as it is expected to appear following launch. He generates 
some test data in this format, and packages it in SFDU labels. Since he has not registered the 
format description, he creates his own ADI by beginning the ADI with a "Z", and packages this 
description with the labeled data. He transfers this product to his colleagues overseas to test their 
preparation to receive the data, and to test his preparation of the product His colleagues discover 
an error in the description of the format and so he revises the description. 

Prior to launch the ground handling system, which will actually create the labeled data objects he 
expects, requires the registered ADI for insertion into the labels they will add to the data. In 
addition, his local software contractor also wants this ADI to insert into a table that will be used to 
direct the local data handling and processing software. This software will not use the format 
description directly, but will incorporate this information into its processing algorithms for 
efficiency. Investigator A registers his format description with die CAO, and provides the ADI and 
description to both the ground handling system and the local software contractor. However he 
informs the CAO that his description is not to be released for 4 months, which he expects to be 
about 3 weeks after launch. This should give him time to look at the data and verify the 
correctness of the description before allowing general use. He also advises the CAO that the 
format description must be revisable following the release date. 

The launch is slipped one month, so he requests the CAO to push back the release date of his 
description by one month. 

Following launch, he begins to receive labeled data objects from the ground handling system and 
his local processing software begins to produce garbage. Investigation reveals that there was an 
error in understanding and documenting how the instrument packed information into a particular 8 
bit word. Therefore he has his local software revised, and submits a revised description to the 
CAO which is labeled version 2 and is noted as an important update. The nature of this update is 
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also described. This error is transparent to the ground handling system since it does not look at 
this information to do its processing. 

Following the release date, he begins to send copies of the data to his colleagues and informs them 
that the CAO has a revised description. He has included this description in the initial data provided 
to them. They proceed to fix their software and to make the data available to others locally. 

After about 6 months, Investigator A notices a mis-spelled name for a field in the format 
description. He wants this corrected at the CAO because he is in the process of preparing 
additional information that will refer to that name. This results in version 3 of the description, 
which is noted as having an editorial change. The nature of the editorial change is described. He 
does not bother to inform his colleagues. 

After about 1 year, the instrument suffers a mode failure that results in the periodic occurrence of 
"all ones" in one of the fields of the format. Fortunately this is predictable and describable in the 
following way; For times greater than TO in word 3, the value of word 5 is fill (all ones) when 
word 10 indicates mode=4. This information needs to be added to the format description to 
improve its correctness for all the labeled data objects carrying the ADI of the format description. 
He provides the new description to the CAO as version 4. At the same time he adds a text 
description of the instrument operation and the calibration coefficients to use in converting values 
to physical units. This version is noted to be an important revision from the previous version, and 
the nature of the revision is described. He notifies his colleagues of this new version. Other 
recipients of the d a ta , who are unknown to him, should periodically check with the CAO or check 
the CA Agent Annual Report to see if new revisions ver s io ns of the description are available. 
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Scenario 2: The Planetary Data System (PDS) has prepared a Data Element Dictionary (DED) 
that it would like adopted within the planetary community. It decides to register this DED with a 
CAO so it may be readily incorporated by reference into the descriptions of a wide range of data. It 
registers this with an immediate release date, and an update status of non-revisable. In this way 
future data producers can be sure that this DED will not change after they have generated labeled 
data objects and descriptions that may refer to this DED. 

After about 12 months, the PDS has accumulated a set of additional terms to be added to the DED. 
A new DED is created and submitted to the CAO for registration. It receives a new ADI which is 
not necessarily related to the old ADI in any visible manner. PDS advertises the existence of this 
new DED and encourages ’ts use, in place of the older DED, for all new data and descriptions. 
However from the point of view of the CAO, this is just another registered MDO with a 
registration date and brief description that will appear in the annual report. It is up to PDS to 
advertise it as a replacement for new work. 
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Scenario 3: The colleagues of Investigator A from Scenario 1 have asked their local CAO to 
obtain the format description submitted by Investigator A to the UARS CAO. This will facilitate 
access to this metadata in their country. 

The local CAO asks the UARS CAO to send the DDP corresponding to the given ADI. The UARS 
CAO agrees, and notes the request for future reference. When Investigator A submits a new 
version, the UARS CAO must forward the new version to the local CAO. In this way the local 
CAO can be current in supporting the latest version to its local users. 
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